home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / e / misc.save / 000055_jaltman2@nyc.rr.com_Fri Jan 19 11:23:18 2007.msg < prev    next >
Internet Message Format  |  2020-01-01  |  5KB

  1. Path: reader2.panix.com!reader1.panix.com!panix!newsfeed-00.mathworks.com!newscon02.news.prodigy.net!prodigy.net!border1.nntp.dca.giganews.com!nntp.giganews.com!nx01.iad01.newshosting.com!newshosting.com!post01.iad01!roadrunner.com!not-for-mail
  2. Date: Fri, 19 Jan 2007 08:22:39 -0500
  3. From: Jeffrey Altman <jaltman2@nyc.rr.com>
  4. Organization: Send private replies to jaltman at mit dot edu
  5. User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
  6. MIME-Version: 1.0
  7. Newsgroups: comp.protocols.kermit.misc
  8. Subject: Re: Macro: Terminal -> Command -> Terminal -> Command?
  9. References: <xwOhh.34809$cz.516497@ursa-nb00s0.nbnet.nb.ca> <lWShh.32651$tb6.31529@news-wrt-01.rdc-nyc.rr.com> <bF8ih.35271$cz.521966@ursa-nb00s0.nbnet.nb.ca> <4589b00f$0$16922$4c368faf@roadrunner.com> <Gmrih.35742$cz.527501@ursa-nb00s0.nbnet.nb.ca> <458a9baa$0$5926$4c368faf@roadrunner.com> <c3_rh.2668$1x.45361@ursa-nb00s0.nbnet.nb.ca>
  10. In-Reply-To: <c3_rh.2668$1x.45361@ursa-nb00s0.nbnet.nb.ca>
  11. Content-Type: text/plain; charset=ISO-8859-1
  12. Content-Transfer-Encoding: 7bit
  13. Lines: 118
  14. Message-ID: <45b0c5ad$0$7740$4c368faf@roadrunner.com>
  15. X-Complaints-To: abuse@rr.com
  16. Xref: panix comp.protocols.kermit.misc:15628
  17.  
  18. What are you expecting
  19.  
  20.    OUTPUT \Kdecf06
  21.    INPUT <n> \Kdecf06
  22.  
  23. to do?
  24.  
  25. Since keyboard escape sequences are not going to be echo'd back to the
  26. terminal for input processing, it is the equivalent of
  27.  
  28.    INPUT <n> "some string that is never ever going to come"
  29.  
  30. You use the INPUT command to wait for the sequence that the host sends
  31. in response to the sequence you sent with OUTPUT.
  32.  
  33.  
  34.  
  35. Scott Caissie wrote:
  36. > Its a pity that it can't be made faster. 1 second is too long when I have a 
  37. > macro using this numerous times per account.
  38. > Anyway, I discovered an oddity.
  39. > Is there a problem with INPUT & Kverbs?
  40. > On of my macros is trying to use F6 (opens a window for me) but it doesn't 
  41. > function if it is by itself.
  42. > I have 3 scenarios listed below.
  43. > Scenario #1 (my original simple setup)
  44. > OUTPUT \Kdecf06
  45. > INPUT 1 \Kdecf06
  46. > The terminal won't update. In fact it acts like INPUT 0 \Kdecf06. Theres no 
  47. > actual pause using 1 rather than 0.
  48. > Scenario #2
  49. > OUTPUT \Klfarr\Kdecf06
  50. > INPUT 1 \Klfarr\Kdecf06
  51. > This also doesn't work....still no actual pause or updating.
  52. > Scenario #3
  53. > OUTPUT \8\Kdecf06
  54. > INPUT 1 \8\Kdecf06
  55. > This works. I was wondering if Kverbs had complications with this.
  56. > I had another macro which uses OUTPUT/INPUT very intensely and occassionally 
  57. > it loses it's place, and I think this might be the reason why. The terminal 
  58. > doesn't seem to always update when it should. Its going to take me about an 
  59. > hour to verify if all my statements are being processed correctly, but 
  60. > before I do that, I want to know precisely what I'm looking for.
  61. > "Jeffrey Altman" <jaltman2@nyc.rr.com> wrote in message 
  62. > news:458a9baa$0$5926$4c368faf@roadrunner.com...
  63. >> The value is a "timeout" period not a time-you-must-wait-for period.
  64. >> You could put 1000 there and it wouldn't make a different provided that
  65. >> the data you are looking for actually arrives.  The value is "how long
  66. >> should I wait if the pattern I was given does not find a match on the
  67. >> incoming data stream?"
  68. >>
  69. >>
  70. >>
  71. >> Scott Caissie wrote:
  72. >>> That is what my tests today showed.
  73. >>> With this, I'll have macros that will be running in a loop for about 
  74. >>> 50-200
  75. >>> times.
  76. >>> For each, I need only one "INPUT 1" statement at the end to update the
  77. >>> screen. Up until that point, using a multitude of INPUT 0s works fine. 1 
  78. >>> of
  79. >>> my projects will need to update the screen twice.
  80. >>> I ran one today a few times in a loop of 119 times. Worked perfectly.
  81. >>>
  82. >>> Though I wish you could allow for fractions of a second. Or an instaneous
  83. >>> forced update command.
  84. >>> That would be my wish list for Version 3.0.
  85. >>>
  86. >>> But this so far has helped me a lot. Thanks.
  87. >>>
  88. >>> - Scott
  89. >>>
  90. >>> "Jeffrey Altman" <jaltman2@nyc.rr.com> wrote in message
  91. >>> news:4589b00f$0$16922$4c368faf@roadrunner.com...
  92. >>>> Scott Caissie wrote:
  93. >>>>> I see. I've been testing this out all day, and it works pretty much the
  94. >>>>> way
  95. >>>>> I was aiming for.  I was never referred to using the INPUT command
  96. >>>>> before,
  97. >>>>> and to be honest, I don't understand it 100% yet. I'm basically 
  98. >>>>> mirroring
  99. >>>>> my
  100. >>>>> actions.
  101. >>>>> I do have a question. Is there restrictions about using INPUT 0 <text>?
  102. >>>>> This example works fine, but if I use INPUT 0 etc, it won't. I check to
  103. >>>>> see
  104. >>>>> if it works by using \Fscrnstr(y,x,n) on a large scale.
  105. >>>>>
  106. >>>>> SET INPUT TERMINAL ON
  107. >>>>> set input echo off
  108. >>>>> clear input-buffer
  109. >>>>> define vega {
  110. >>>>> ..LZ_PRO := \Fscrnstr(0,6,8)
  111. >>>>> OUTPUT \5\5\5\5\5\5\5\5\57\49\13\49\52\13\m(LZ_PRO)\24
  112. >>>>> INPUT 1 \5\5\5\5\5\5\5\5\57\49\13\49\52\13\m(LZ_PRO)\24
  113. >>>>> for \%t 1 24 1 {
  114. >>>>> echo \Fscrnstr(\%t,0,79)
  115. >>>>> }
  116. >>>>> }
  117. >>>> If you use "INPUT 0 <text>" you are not reading any data from the
  118. >>>> connection.  You must use a timeout greater than 0 in order to process
  119. >>>> data.
  120. >>>>
  121. >>>> Jeffrey Altman
  122. >>>